Rollup of 16 pull requests - #161949

… on different platforms + fixed BSD-based systems to use fchmodat with AT_SYMLINK_NOFOLLOW

…tored non-BSD-based/non-Linux platforms to use OpenOptions open + set_permissions, and refactored tests accordingly

…ns ENOTSUP (e.g. for Ubuntu 20.04 returns ENOTSUP on non-symlinks + symlinks when using fchmodat with AT_SYMLINK_NOFOLLOW). Update docs accordingly as well and corrected behavior + docs for other Unix platforms with symlinks should return `FilesystemLoop` error instead of `InvalidInput` due to not setting `OpenOptions` with read enabled.

Co-authored-by: Rachel Barker <rachel.barker@ferrous-systems.com>

…d fchmodat platform call on fchmodat and every platform falls back to open + fchmod when _res is set to ErrorKind::Unsupported; updated docs to reflect change

seek(SeekFrom::End(0)) special-cased the offset to the UEFI
0xFFFFFFFFFFFFFFFF "set position to end of file" sentinel, then returned
that value as the new stream position. so seek reported u64::MAX instead
of the file size, and the default Seek::stream_len did too. compute the
offset from the file size in every End case instead.

… r=clarfonthey

Refactored docs for `std::fs::set_permissions_nofollow` + fix BSD-based systems to use fchmodat with AT_SYMLINK_NOFOLLOW flag

This PR refactors documentations for `std::fs::set_permissions_nofollow` and fixes BSD-based systems + Android to use `fchmodat` with `AT_SYMLINK_NOFOLLOW` flag (instead of no flag set) and refactors all other platforms to defer to `OpenOptions` with `O_NOFOLLOW` behavior.

r? @clarfonthey
Since they looked at the original `set_permissions_nofollow` PR I made

cc @RalfJung

std: optimise IO error formatting

The current OS error formatting logic goes through a bit of trouble (the `format!` macro, temporary allocations and unnecessary copying) to create a `String` for `Formatter::write_str`. It's more efficient and arguably simpler to have the formatting logic write into the `Formatter` directly instead.

…ures, r=nikic

attach global target features to module-level assembly

fixes rust-lang#80608
fixes rust-lang#127269

At long last, we can forward global target features to LLVM and it will preserve the target features a block of module-level assembly was defined with through LTO.

cc @nikic (who made this happen)
cc @RalfJung any nasty side-effects we might be overlooking here?

…, r=nia-e

implement [u8]::split_ascii_whitespace

Had to create a new pr because in the previous one i somehow deleted all the commits with git.
Tracking issue: rust-lang#147878
[u8] is also missing normal split_whitespace, but that seems like an issue for another pr.

…er_types, r=BoxyUwU

fix ICE in generic_const_parameter_types with inherents

tracking issue: rust-lang#137626

relevant PR where the code was added: rust-lang#154853 (fyi ping @lapla-cogito - nws that this was buggy, it's extreeeemely subtle and easy to miss! ❤️ I mean, I also reviewed that PR and missed it too :3 )

discovered when implementing a change that explicitly tracks whether the args for inherent associated consts are in "self form" or "impl form"

Following along the test case:

- `normalize_canonicalized_inherent_projection` is called with `AliasTermKind::InherentConst` with the generic args being in "self form", i.e. `[ThreeTypes<u8, u16, u32>]`
- `traits::normalize_inherent_projection` is called with said alias
  - it calls `compute_inherent_assoc_term_args`, which does the dance of generating fresh vars for each param in the impl block, equating with the self type, and returning what the fresh vars solved to. This converts from "self args" to "impl args", i.e. `[u8, u16, u32]`
  - it then calls `const_of_item` and instantiates with `[u8, u16, u32]`. this is correct and good, `const_of_item` expects "impl form" args.
  - it then calls `push_const_arg_has_type_obligation`
    - which calls `type_of` and instantiates with `[u8, u16, u32]` to fetch the type of the const, to be able to register a `ConstArgHasType`. this is correct and good, `type_of` expects "impl form" args.
  - `traits::normalize_inherent_projection` returns, dropping the impl form args it computed
- `normalize_canonicalized_inherent_projection` calls `ocx.register_obligations(const_arg_has_type_obligation(...))`, passing `goal`. Remember that `goal` has the original "self args" generic arg format.
  - `const_arg_has_type_obligation` calls `type_of` and instantiates with `[ThreeTypes<u8, u16, u32>]`. This is no good very bad!! `type_of` expects "impl form" args, not "self form"!!
  - ICE!! `type parameter T3/rust-lang#2 (T3/rust-lang#2/2) out of range when instantiating, args=[ThreeTypes<u8, u16, u32>]`

The reason I filed this under `feature(generic_const_parameter_types)` is because for this bug to manifest, `type_of` must return a type that actually references a generic param to be able to trigger an ICE. Otherwise, the buggy incorrect args are silently ignored and compilation continues "fine".

The fix:

`normalize_inherent_projection` already registers a `ConstArgHasType`. why are we doing it a second time. just delete it. 💀

r? @BoxyUwU

…ius-help-default, r=Kivooeo

Report the configured Polonius default in -Z help

Fixes rust-lang#161543

…Urgau

Add rustdoc-html regression test for generated macro

Fixes rust-lang#79289.

I like when bugs are already fixed. =D

r? @Urgau

…oxyUwU

Retroactively add relnotes for `bool::{ok_or,ok_or_else}` (1.98.0)

Looks like this was lost:

- Relnotes issue: rust-lang#156336
- Tracking issue: rust-lang#142748
- Stabilization PR: rust-lang#156594

Closes rust-lang#156336.